Encoding Semi-Structured Data for Efficient Search and Browsing

ABSTRACT

A method for encoding XML tree data that includes the step of encoding the semi-structured data into strings of arbitrary length in a way that maintains non-structural and structural information about the XML data, and enables indexing the encoded XML data in a way that facilitates efficient search and browsing.

This is a Divisional of U.S. patent application Ser. No. 11/979,196filed on Oct. 31, 2007, which is a Divisional of U.S. patent applicationSer. No. 10/931,035 filed on Sep. 1, 2004, which is a continuation ofU.S. patent application Ser. No. 09/791,579, which is herebyincorporated by reference in its entirety.

FIELD OF THE INVENTION

The present invention is in the general field of accessing dataincluding but not limited to eXtensible Markup Language (XML) documents.

BACKGROUND OF THE INVENTION

There follows a glossary of conventional terms. The meaning of terms isgenerally known per se and accordingly the definitions below areprovided for clarity and should not be regarded as binding.

GLOSSARY OF TERMS

Data—Information that one wants to store and/or manipulate.

Database—A collection of data organized by some set of rules.

Attribute—A feature or characteristic of specific data, represented e.g.as “columns” in a relational database. A record representing a personmight have an attribute “age” that stores the person's age. Each columnrepresents an attribute. In XML (XML is defined below), there is an“attribute” that exists as part of a “tag.”

Column—In a relational database, columns represent attributes forparticular rows in a relation. For example, a single row might contain acomplete mailing address. The mailing address would have four columns(“attributes”): street address, city, state, and zip code.

Record—A single entry in a database. Often referred to as a “tuple” or“row” in a relational database.

Tuple—See “record”

Row—See “record”

Table—See “relation”

Relation—A way of organizing data into a table consisting of logicalrows and columns. Each row represents a complete entry in the table.Each column represents an attribute of the row entries. Frequentlyreferred to as a “table.”

Relational database—A database that consists of one or more “relations”or “tables”.

Database administrator—A person (or persons) responsible for optimizingand maintaining a particular database

Schema—The organization of data in a database. In a relational database,all new data that comes into the database must be consistent with theschema, or the database administrator must change the schema (or rejectthe new data).

Index—Extra information about a database used to reduce the timerequired to find specific data in the database. It provides access toparticular rows based on a particular column or columns.

Path—A series of relationships among data elements. For instance, a pathfrom a grandson to grandfather would be two steps: from son to father,and from father to grandfather.

Structure—The embodiment of paths in particular documents or data. Forexample, in a “family tree,” the structure of the data is hierarchical:it is a tree with branches from parents to children. Data without ahierarchical structure is often referred to as “flat.”

Query—A search for information in a database.

Range query—A search for a range of data values, like “all employeesaged 25 to 40.”

I/O—A read from a physical device, such a fixed disk (hard drive). I/Ostake a significant amount of time compared to memory operations: usuallyhundreds and even thousands of times (or more) longer.

Block read—Reading a fixed sized chunk of information for processing. Ablock read implies an “I/O” if the block is not in memory.

Tree—A data structure that is either empty or consists of a root nodelinked by means of d (d≧0) pointers (or links) to d disjoint treescalled subtrees of the root. The roots of the subtrees are referred toas “child nodes” of the root node of the tree, and nodes of the subtreesare “descendent nodes” of the root. A node in which all the subtrees areempty is called a “leaf node.” The nodes in the tree that are not leavesare designated as “internal nodes.”

In the context of the invention, leaf nodes are also nodes that areassociated with data.

Nodes and trees should be construed in a broad sense. Thus, thedefinition of tree encompasses also a tree of blocks wherein each nodeconstitutes a block. In the same manner, descendent blocks of a saidblock are all the blocks that can be accessed from the block. Fordetailed definition of “tree,” also refer to the book by Lewis andDeneberg, “Data structures and their algorithms.”

B-tree—A tree structure that can be used as an index in a database. Itis useful for exact match and range queries. B-trees frequently requiremultiple block reads to access a single record. A more completedescription of B-trees can be found on pages 473-479 of The Art ofComputer Programming, volume 3, by Donald Knuth (® 1973,Addison-Wesley).

Hash table—A structure that can be used as an index in a database. It isuseful for exact match queries. It is not useful for range queries. Hashtables generally require one block read to access a single record. Amore complete description of hash tables can be found on e.g. pages473-479 of The Art of Computer Programming, volume 3, by Donald Knuth (®1973, Addison-Wesley).

Inverted list—A structure that can be used as an index in a database. Itis a set of character strings that points to records that containparticular strings. For example, an inverted list may have an entry“hello.” The entry “hello” points to all database records that have theword “hello” as part of the record. A more complete description ofinverted lists can be found on e.g. pages 552-559 of The Art of ComputerProgramming, volume 3, by Donald Knuth (® 1973, Addison-Wesley).

Semi-structured data—Data that does not conform to a fixed schema. Itsformat is often irregular or only loosely defined.

Data mining—Searching for useful, previously unknown patterns in adatabase.

Object—An object is some quantity of data. It can be any piece of data,a single path in a document path, or some mixture of structure and data.An object can be a complete record in a database, or formed “on the fly”out of a portion of a record returned as the result of a query.

Markup—In computerized document preparation, a method of addinginformation to the text indicating the logical components of a document,or instructions for layout of the text on the page or other informationwhich can be interpreted by some automatic system.(from the Free On-LineDictionary of Computing—http://wombat.doc.ic.ac.uk/foldec)

Markup Language—A language for applying markup to text documents toindicate formatting and logical contents. Mark up languages areincreasingly being used to add logical structure information todocuments to enable automated or semi-automated processing of suchdocuments. Many such languages have been proposed, ranging from genericones such as SGML and XML, to industry or application-specific versions.

SGML—A specific example of Markup Language, Standard Generalized MarkupLanguage. SGML is a means of formally describing a language, in thiscase, a markup language. A markup language is a set of conventions usedtogether for encoding texts (e.g., HTML or XML).

XML—A specific example of Markup Language eXtensible Markup Language. Alanguage used to represent semi-structured data. It is a subset of SGML.XML documents can be represented as trees.

Key—An identifier used to refer to particular rows in a database. In thecontext of relational database, keys represent column information usedto identify rows. For instance, “social security number” could be a keythat uniquely identifies each individual in a database. Keys may or maynot be unique.

Join—A method of matching portions of two or more tables to form a(potentially much larger) unified table. This is generally one of themost expensive relational database operations, in terms of space andexecution time.

Key search—The search for a particular value or data according to a keyvalue. This search is usually performed by an index.

Search—In the context of data, searching is the process of locatingrelevant or desired data from a (typically much larger) set of databased on the content and/or structure of the data. Searching is oftendone as a batch process, in which a request is submitted to the system,and after processing the request, the system returns the data orreferences to the data that match the request. Typical (yet notexclusive) examples of searching are the submission of a query to arelational database system, or the submission of key words to a searchengine on the World Wide Web.

Path search—The search for a particular path in the database. A “path”is a series of relationships among data elements. For instance, part ofan invoice might have the “buyer,” and that buyer has an “address” onthe invoice. A search for the address of all buyers is really for thepath “invoice to buyer to address.” This is a search for a particularstructure, which is different from key search (the search for particularvalues). Path search and key search may be combined.

Browsing in the context of data, browsing is the process ofinteractively locating relevant or desired data by wandering ornavigating through a (typically much larger) set of data. Browsing canbe done based on data content, structure, or a combination of these. Acommon example of browsing is the traversal of hyperlinks in the WorldWide Web in order to locate relevant web pages.

Access—In the context of data, access is the process of obtaining data,typically through searching, browsing, or through following references.

Sibling—Elements of a tree that share the same parent are siblings. Thisis the same sense as brothers and sisters are siblings.

Tag—An XML tag represents structural information in an XML document. Atag may or may not surround data and may or may not contain other tags.All tags have a parent, except the first tag. Additionally see “markup.”

Parent-child—In a tree, a child is an element that branches from itsparent. In XML, if “tag1” immediately surrounds “tag2,” then “tag1” isthe parent of “tag2.” “Tag2” is the child of “tag1.”

Token—A short pattern used to represent another pattern.

Complete-key indexing—An indexing method that stores the key as part ofthe index. This provides an exact “hit or miss” result when using theindex, but is very large when the keys are large. This is contrastedwith a “compressed-key indexing.”

Compressed-key indexing—A compressed-key index does not store the entirekey in the index, thus can be significantly smaller than a complete-keyindex (for the same keys). However, it may provide “false positives”(that can be removed later). It should not miss relevant records (“falsenegatives”). This is contrasted with a “complete-key indexing.” ACompressed-key indexing is described e.g. in U.S. Pat. No. 6,175,835.

Encoding—Transforming one representation into a different, equivalentrepresentation. For example, representing the Roman numeral “VII” as thedecimal number “7” is a form of encoding.

Sibling Order—Semi-structured data stored in files have a specific“order” associated with the data. In a race, finishers are ordered basedon their order of appearance across the finish line: “first,” “second,”“third,” etc. With semi-structured data, siblings can be ordered bytheir appearance in the document.

Semantic information—“Of or relating to meaning, especially meaning inlanguage.” (The American Heritage® Dictionary of the English Language,Third Edition, © 1996, 1992 by Houghton Mifflin Company) The differencebetween the word “orange” used to represent a color and the word“orange” to represent a fruit is a “semantic” difference. “Semanticinformation” is information about the meaning of tags and data.

Syntactic information—Syntax is the study of the rules whereby words orother elements of sentence structure are combined to form propersentences. “Syntactic information” in semi-structured data representsthe tags and data, without information regarding the meaning of the tagsand data.

Homonym—A word that is used to designate several different things. Theword “bow” represents a stringed weapon, the front of a ship, and a loopof ribbon, among other things. When used with more than one semanticmeaning, “bow” would be an example of a homonym.

Synonym—A word having the same or nearly the same meaning as anotherword in a language. Words like “top,” “peak,” and “apex” are synonyms inEnglish.

BACKGROUND

The most popular database today is the relational database. In arelational database, data is stored in relations (or “tables”). Tableshave columns and rows. The rows are often referred to as “records” andconsist of a single related group of data, like a complete mailingaddress. The columns in the tables represent attributes of the rows. Acolumn in a mailing address table might be “Zip Code,” just one part ofa row.

Relations are defined by a database administrator, and have a fixedformat called a “schema.” For instance, the schema for a mailing addressrelation might be (name, address, city, state, zip), which is a “name”followed by an “address” followed a “city,” etc. Each mailing addressthat appears in the table has to have that exact format. Changes to theschema are quite expensive, and result in significant “downtime” for thedatabase.

The database administrator also builds initial indexes. An index is adata structure that provides very quick access to particular rows, basedon particular data values. For instance, a database administrator couldmake an index over the “zip” column that would make searching for zipcodes very fast. Building new indexes over an existing relation can bequite expensive (insofar as space and processing time is concerned).

Relational databases generally index the data using variants of B-trees,hash tables, and inverted lists. These indexes provide good performancewhen the schema is fixed, and when the database administrator hascreated specific indexes for expected queries. It is generally quiteexpensive when users wish to perform a query that cannot use an existingindex.

As specified above, data that do not conform to a fixed schema arereferred to as semi-structured. This type of data is often irregular andonly loosely defined. Even in the previous example of a mailing address,one can see how semi-structured data could be used. Imagine a databasethat takes global mailing addresses. Some addresses would have citiesand states, some would include country and country designator, somewould have numeric zip codes, some alphanumeric postal codes, and manywould include extra information like “office number.” They would be verydifferent, depending on where they originated. In all cases, though,even though they do not look the same, they are still instances of a“mailing address.”

Perhaps the prime example of semi-structured data is the contentavailable on the Web. On the web, semi-Structured data is the rule, notthe exception. Just storing and searching simple web pages is difficultbecause they are all so different. Semi-structured data also appears inbusiness and scientific applications that access (or generate)heterogeneous data stores. Even a simple task like data mining in adatabase of customer purchases, where the data comes from a seeminglystructured source, has at its core a semi-structured datarepresentation: the “shopping basket.” Every shopping basket isdifferent, and a collection of such baskets is a semi-structured source.

Unlike the relational data stored in a typical database, semi-structureddata does not have a strict schema and does not have to conform to apreset format. Because of this, semi-structured data is more interestingat this time since storage and searching mechanisms are fairly new, byindustry standards.

In searching semi-structured data, queries often include informationabout the structure of the data, not just field contents. For instance,genealogists may care about the grandchildren of a particular historicalfigure. Such data paths (e.g., the path from “grandparent” to“grandchild”) are often explicit in the semi-structured data, but arenot stored explicitly in a relational database. At the same time,semi-structured data may be queried over particular attributes,independent of the structure that surrounds those attributes (e.g. keyword search).

Also, queries may contain structural constraints about the objectsreturned. For instance, one may be interested only in “restaurantobjects” that minimally have a name and address associated with them.These are not queries solely associated with semi-structured data, butthe types of queries that may be encountered, and that an effectiveindex should account for. A more detailed discussion of paths insemi-structured data can be found in, e.g. “Keys for XML,” Buneman, etal., August 2000.

Relational databases that store structured data are going through aprocess of incremental refinement, realizing gains in performance at anever-slowing pace. Semi-structured storage solutions at this time areneither mature nor standardized. Most storage and indexing systemsshoehorn semi-structured data into some well-understood structural formsuch as relational format. This is far from being a practical, scalablesolution and there is accordingly room for significant improvement.

There follows discussion in connection with a specific instance ofsemi-structured data, i.e. the popular XML (eXtensible Markup Language)data. Various academic papers and emerging products focus on thegeneration, storage, and search of XML. XML has been considered the“lingua galactica” for content exchange over the Internet because it canbe used to encode any arbitrary type and quantity of information. As theconsideration of XML has progressed, it has become apparent that it isalso an important way to store and search information, not just totransmit it. This importance is reflected in significant industryattention as evidenced e.g. in “Oracle8i-The XML Enabled Data ManagementSystem,” by Banerjee, et al. and “XML and DB2,” by Cheng and Xu.

XML is a well-understood subset of SGML (Standard Generalized MarkupLanguage) that has received significant attention in recent years as thecandidate for a clear standard representation of semi-structured data.With a growing proportion of electronic business traffic moving to XML,a reliable, scalable, efficient storage and retrieval solution isbecoming critical.

The need to handle semi-structured data is growing in step withincreasing business outsourcing, systems integration, mergers andacquisitions, and the explosive growth in information available on theInternet. The new e-commerce era sets new demands on data andinformation exchange. Wherever any two non-identical data sources cometogether, the choice is costly translation and mediation, specific tothose two sources, or an effective semi-structured search and storagesystem.

In the past, business data generally had to have a significant amount ofstructure in order to be stored and searched efficiently. That is not tosay semi-structured data is in any way a new idea, it was frequentlyavoided before because it can be expensive and difficult to deal with.

Within an organization, some designating authority can specify standarddata representations, and all of the data creators and users expect andunderstand the canonical data format. Within larger organizations,multiple standards may emerge within departments or divisions, andexpensive custom translators can be built and maintained to transferdata between organizational units. Between organizations however, theproblem becomes intractable. There are simply too many formats to dealwith.

Traditional storage and querying then happened only at theorganizational level, and often with just a fraction of anorganization's data. There were significant restrictions on how thisdata could be organized, as well, if it was stored in a commercialdatabase. These restrictions mean that every object in a relation hasthe same organization, and is just as likely to be over-specified orunder-specified, just to fit it into the current mold.

If the data do not have a fixed schema, however, it can be nearlyimpossible to get good storage and query results from a relationaldatabase. The hitherto known solutions for storing XML and othersemi-structured data typically use relational databases and generallyrequire breaking the XML apart into chunks that can fit into a table,with non-conforming pieces going into overflow bins of some sort. ForXML that is quite different from current database data, new relationsare created. For each new relation created, search becomes slower andmore difficult.

Even with this approach, intelligent search is still often difficult.The tables are flat structures, in rows and columns, with little obviousindication about the underlying data's structure. The data in a relationis like logs on a woodpile: so many rows high, so many columns wide. ButXML is like a complete tree, with paths and branches and leaves. Imaginesearching the woodpile for the “third branch on the left, 17′ high inthe tree.” You could do it by piecing the tree back together from thewoodpile, rebuilding the tree until you found your answer, then stackingthe wood back on the pile when you were done. This simplified exampleillustrates how relational databases storing XML data work.

The treatment of both structured and semi-structured data is usually byindex schemes that have A) uniform key structure, and B) do not storecomplete relationships. Because relational databases break documentsapart into tables, some information is no longer explicit in thedatabase and must be reconstructed for each search. For example, aninvoice might have a fixed set of fields (i.e., “shipping address” and“billing address”) that get stored in one table, and an arbitrary set offields (i.e., the items on the invoice) that get stored in anothertable. This is frequently done because it can save a considerable amountof storage space. However, when there is a search that uses one of therelationships that is natural part of the original invoice, but has beensplit into multiple tables to save space, an expensive reconstruction(i.e., a “join”) must occur. This leads to two significant problems:large index size and expensive search for structure.

Searching for structure (“path search”) is necessary in certainapplications, but prohibitively expensive in relational databases.Imagine a genealogy database that stores census records and informationabout family trees. Each person would likely be represented as an objectin a relation, and that person would have a set of two biologicalparents. Since the number of children a person has can vary, thechildren of a person are simply not stored in the same record or inaccordance with another solution a large number of slots are allocatedin order to accommodate (possibly) many children. In most cases where aperson has an average or less number of children most of the slots wouldbe empty. The first solution (not storing children) would be good interms of database size, since one can tell person A's children by seeingwho has person A as a parent. The second option (having many mostlyempty children slots) makes searching for children quicker, but at theexpense of disk space (and database size).

Using this genealogy database, try to find “All of George Washington'sliving descendents.” First George Washington is found in the database,hopefully very quickly, and figure out who his children were. Then hischildren's records are searched in order to find out who their childrenwere. Third type of search is continued, again and again, repeatedlyinspecting data (the tree is rebuild from the woodpile). Every time thenext generation is encountered, the problem requires an expensive join,or difficult successive query rewrites. The resulting living descendentsare eventually obtained after significant work and many I/O operations.

With the popular available indexes for relational databases (e.g.B-trees, hash tables, inverted lists), searching for XML paths willalways be difficult because the document structure is lost in thetranslation to relations. Every significant new document format requiresa new relation. And in order to search this new type of relation, thedatabase administrator must come in and explicitly create new indexes.

A relational mapping of XML into a database is not the only possibility.It is also feasible to map XML data to objects in an object-oriented(OO) database management system. There are clear reasons to store andsearch semi-structured sources using the relatively ineffectivemechanisms available in relational systems over object-orienteddatabases in many instances. There are also reasons to favor OOdatabases over their relational counterparts.

In choosing an OO solution, there is significant overhead associatedwith storing the data. First, XML data elements must be tagged withunique object identifiers (“OIDs”) so that they can be later found inthe database. This overhead can swell the size of the data. Thisincrease in size occurs well before any indexes to aid search are built.Once indexes are built to aid the search, the OO solution requires evenmore space.

Furthermore, OO databases generally use index structures that are quitesuitable for relational systems, and support relational style queries.B-trees and hash tables and inverted lists are commonly used to indexthe data in OO databases. As such, even though the semi-structured datamay be stored easily, querying the data suffers the identical problemsof relational systems. B-trees quickly become quite large and unwieldy.Hash tables prevent range queries. Data relationships are not capturedby the indexes. Thus, OO databases, as they currently stand, are not anadequate solution for storing XML data.

As organizations trade increasing amounts of information, the number ofdata formats that must be understood grows unfettered. Existing databasesolutions do not scale well to meet this demand. When dealing withsemi-structured data, it is important to be able to map and maintain therelationships present in the data. Buneman, Fan, and Weinstein note in“Query Optimization for Semi-structured Data using Path Constraints in aDeterministic Data Model” that paths represent important semantic cluesabout semi-structured data. If these clues are lost or not easilyaccessible because of the database and its indexes, the database hasfailed in its tasks.

There are more tasks for an effective database and indexing system forsearching and storing semi-structured data. Simple text searches arerequired of any relational and semi-structured database. The ability todo path searches is an important additional burden placed onsemi-structured databases. A path search is especially useful when thesought type of data is known, but not exactly where it is in thedatabase. For instance, a query like “find all addresses of all buyersof all invoices” is a search for the path “invoice→buyer→address.” Theexample of this type of path is illustrated in FIG. 2. In addition tosearching for particular paths, one should be able to search forparticular structures within the semi-structured data, like a completeset of “buyer” information, which includes the buyer's name and address.

Finally, since the data is semi-structured, and its organization is notalways known, the ability to “browse” the data is also important. Whenbrowsing the data, users hop from elements to children, or back to anelement's parent: it is a way to “wander” through the data in adatabase. Looking again at the document in FIG. 1, once the user is at“Invoice,” she can see that there are “Buyers,” “Sellers,” “Numbers,”and “Item Lists” available. The user can then follow one of thesebranches, say “Buyer,” to find that “Buyers” have “Name” and “Address”fields associated with them.

The requisite task set for effectively indexing and searchingsemi-structured data is significantly larger than for structured datasources. Quite simply, the lack of a schema makes the problem muchharder than before. Our proposed structures and techniques solve theproblems and overcome the new burdens presented by XML and other formsof semi-structured data.

There is accordingly a need in the art to provide for a technique thatfacilitates encoding of semi-structured data which facilitates indexingof the data for efficient search.

There is another need in the art to provide for a technique of the kindspecified that is particularly useful for indexing and searching MarkupLanguage (ML) data in general and eXtensible Markup Language inparticular.

There is still another need in the art to provide a technique whichfacilitates text search, path search, and browsing in semi-structureddata in general and ML data in particular.

SUMMARY OF THE INVENTION

In the context of the invention efficient access means the ability tolocate relevant data in a short amount of time or with only a smallnumber (e.g., several) disk accesses, even though the data items storedmay number in the millions or more, or even though the total size of thedata items is such that they cannot all fit in the memory available tothe search process. Efficient access refers to the overall or typicalbehavior of the system. In other words, while individual accesses maysometimes be inefficient, the access behavior observed over time isefficient.

As is well known, semi-structured data includes as an instance theMarkup Languages. The Markup languages include numerous instancesincluding but not limited to LaTeX, TeX, RDF, SVG, SMIL, XCML, XML,XHTML, SGML, HTML, VRML, DHTML, VML, JAML, QAML, DML, MRML, SSML, ThML,TDML, OML, CKML, STML, PHML, CML, DCML, CFML, PGML, MGML, CelIML,AnatML, FieldML, XGMML.

For convenience of explanation only the invention is described withreference to XML. Those versed in the art will readily appreciate thatthe invention is, likewise, applicable to other instances of MarkupLanguage, and more generally to any semi-structured data.

The invention provides for a method for encoding semi-structured data,comprising:

-   -   a) providing a semi-structured data input;    -   b) obtaining an encoded semi-structured data by selectively        encoding at least part of said semi-structured data into strings        of arbitrary length in a way that (i) maintains non-structural        and structural information associated with the semi-structured        data, and (ii) the so encoded semi-structured data can be        indexed for efficient access.

The invention further provides for a method for constructing a metadatadictionary in respect of semi-structured data, comprising:

-   -   a) providing a semi-structured data input;    -   b) constructing a metadata dictionary that facilitates        compressed encoding of at least part of said semi-structured        data into strings of arbitrary length in a way that at least        maintains non-structural and structural information associated        with the semi-structured data.

Still further, the invention provides for a method for encoding andindexing semi-structured data, comprising:

-   -   a) providing a semi-structured data input;    -   b) obtaining an encoded semi-structured data by selectively        encoding at least part of said semi-structured data into strings        of arbitrary length in a way that (i) maintains non-structural        and structural information associated with the semi-structured        data;    -   c) indexing the encoded semi-structured data using layered        index; the layered index includes basic partitioned index        structure; said layered index maintains a balanced structure of        blocks.

The invention further provides for a method for encoding and indexingMarkup Language (ML) data, comprising:

-   -   a) providing an ML data input;    -   b) obtaining an encoded ML data by selectively encoding at least        part of said ML data into strings of arbitrary length in a way        that (i) maintains non-structural and structural information        associated with the semi-structured data;    -   c) indexing the encoded semi-structured data using layered        index; the layered index includes basic partitioned index        structure; said layered index maintains a balanced structure of        blocks.

Yet further, the invention provides for a method for encoding andindexing semi-structured data, comprising:

-   -   a) providing a semi-structured data input;    -   b) selectively encoding at least part of said semi-structured        data into keys of arbitrary length in a way that (i) maintains        non-structural and structural information associated with the        semi-structured data;    -   c) creating a balanced index structure over the arbitrary-length        keys.

The invention further provides for a method for indexing semi-structureddata, comprising:

-   -   (a) providing a semi-structured data input that include data        items;    -   (b) indexing keys of the data items of the said semi-structured        data such that with about no more than 25,000 bytes of internal        memory per 1 million data items it is possible to locate an        address of any such said data item with no more than 2 I/Os,        irrespective of the size of the key.

The invention provides for a method for indexing markup language (ML)data, comprising:

-   -   (a) providing an ML data input that include data items;    -   (b) indexing keys of the data items of the said ML data such        that with about no more than 25,000 bytes of internal memory per        1 million data items it is possible to locate an address of any        such said data item with no more than 2 I/Os, irrespective of        the size of the key.

A system for encoding semi-structured data, comprising:

-   -   storage for storing a semi-structured data input;    -   processor node configured to construct an encoded        semi-structured data by selectively encoding at least part of        said semi-structured data into strings of arbitrary length in a        way that (i) maintains non-structural and structural information        associated with the semi-structured data, and (ii) the so        encoded semi-structured data can be indexed for efficient        access.

The invention provides for a system for encoding and indexingsemi-structured data, comprising:

-   -   storage for storing a semi-structured data input;    -   processor node configured to construct an encoded        semi-structured data by selectively encoding at least part of        said semi-structured data into strings of arbitrary length in a        way that (1) maintains non-structural and structural information        associated with the semi-structured data;    -   processor node configured to construct an indexing of the        encoded semi-structured data using layered index; the layered        index includes basic partitioned index structure; said layered        index maintains a balanced structure of blocks.

The invention further provides for a system for encoding and indexingMarkup Language (ML) data, comprising:

-   -   storage for storing an ML data input;    -   processor node configured to construct an encoded ML data by        selectively encoding at least part of said ML data into strings        of arbitrary length in a way that (i) maintains non-structural        and structural information associated with the semi-structured        data;    -   processor node configured to construct an indexing of the        encoded semi-structured data using layered index; the layered        index includes basic partitioned index structure; said layered        index maintains a balanced structure of blocks.

Yet further, the invention provides for a system for encoding andindexing semi-structured data, comprising:

-   -   storage for storing a semi-structured data input;    -   processor node configured to selectively encoding at least part        of said semi-structured data into keys of arbitrary length in a        way that (i) maintains non-structural and structural information        associated with the semi-structured data;    -   processor node configured to creating a balanced index structure        over the arbitrary-length keys.

The invention provides for a storage medium storing data indicative ofencoded semi-structured data that includes strings of arbitrary lengththat (i) maintains non-structural and structural information associatedwith the semi-structured data, and (ii) the so encoded semi-structureddata can be indexed for efficient access.

The invention further provides for in a computer system having a storagemedium of at least an internal memory and an external memory;

-   -   a data structure that includes an index over the keys of the        data items; the index is arranged in blocks, such that with        about no more than 25,000 bytes of internal memory per 1 million        data items it is possible to locate an address of any such said        data item with no more than 2 I/Os access to the external        memory, irrespective of the size of the key.

BRIEF DESCRIPTION OF THE DRAWINGS

For a better understanding, the invention will now be described, by wayof example only, with reference to the accompanying drawings, in which:

FIG. 1 illustrates an example XML document;

FIG. 2 is an intermediate tree representation of the XML document ofFIG. 1, in accordance with the prior art;

FIG. 3 is an intermediate tree representation of the XML document ofFIG. 1, where tags and attributes are replaced by tokens, in accordancewith a preferred embodiment of the invention;

FIG. 4 illustrates an exemplary token dictionary that is utilized in theprocess of encoding strings of arbitrary length, in accordance with apreferred embodiment of the invention;

FIG. 5 is an intermediate tree representation of FIG. 3 with a specialtoken for preserving ordinal information, in accordance with an exampleof a preferred embodiment of the invention;

FIG. 6 illustrates the resulting encoded strings of arbitrary length inaccordance with an example of a preferred embodiment of the invention;

FIG. 7 illustrates the mapping result of the XML document of FIG. 1 intodesignated data records in accordance with a specific embodiment of theinvention;

FIG. 8 illustrates a Patricia structure over designated records inaccordance with a specific embodiment of the invention;

FIG. 9 illustrates the result of implicitly maintaining the designatorsin the index structure of FIG. 8;

FIG. 10 illustrates the structure of FIG. 9, partitioned into blockswith an additional representative index;

FIG. 11 exemplifies an alternative path (Smart Path) to data recordsrepresenting specific parts (names) in the original XML document of FIG.1, in accordance with one embodiment of the invention;

FIG. 12 illustrates schematically a Shortcut Path Optimization inaccordance with one preferred embodiment of the invention; and

FIG. 13 illustrates a typical yet not exclusive example of a computersystem in accordance with one embodiment of the invention.

DESCRIPTION OF PREFERRED EMBODIMENTS

XML documents are tree structures, with both sibling and parent-childrelationships. Child nodes represent subordinate relationships.Parent-child relationships (aka “subordinate”) are illustrated in theXML data (10—referred to also as XML document) of FIG. 1. The Name tagand Address tag are the children of Buyer tag; the Name tag and Addresstag are also siblings. ItemList is the parent of three Item childrenand, as shown, Item tags are “subordinated to” the ItemList tag. Thecode of FIG. 1 will serve as an example for explaining the underlyingconcepts of the invention.

The sample XML document in FIG. 1 represents a tree. The correspondingintermediate tree (20) is illustrated in FIG. 2. tags (e.g. Buyer,Seller and Number 21 to 23, respectively) are stored in boxes with solidoutlines, attributes (e.g. Count, Discount 24 and 25, respectively) arestored in octagons, and data items associated with tags (“labels” suchas ABC Corp. and 123 Industry Way, 26 and 27, respectively) are storedin boxes with dashed outlines. FIG. 2 shows all XML attributes asequivalent. The attributes and their associated properties will bediscussed later in the document.

The intermediate tree (20) in FIG. 2 is built from the XML document (10)in FIG. 1, by performing the following steps:

-   -   1. All tags are represented as solid boxes, with their tag name        appearing in the box.    -   2. All text data appearing within a tag appears as a child, and        is surrounded with a dashed box.    -   3. All attributes of a tag appear in a solid hexagon.    -   4. All nested tags are represented as children, For each child        of a tag, steps 1-3 are repeated for the child.

In accordance with the invention, a metadata dictionary is built. In thefollowing a specific embodiment thereof, a token dictionary isdescribed. The invention is not bound by this specific example ofmetadata dictionary.

In accordance with this preferred embodiment, tokens are used to encodeXML components such as, in a preferred embodiment, tags and attributes.By this preferred embodiment a token dictionary is a collection of tagsand attributes and their associated tokens. By a simplified analogy, inan English Dictionary, words are defined by their entries and the tokendictionary tags are defined by their entries. Each tag type indexedcorresponds to one or more tokens in the token dictionary. The sameapplies to attributes.

As will be shown later, the token dictionary enables not only theencoding of the XML data elements into strings, but also provides afirst level of compression in that the so encoded strings will beshorter than their counterpart XML elements.

Next, as a preparatory step for the subsequent indexing, theintermediate tree structure of FIG. 2 is mapped to a tree where tags andattributes are replaced by tokens, using, to this end, the tokendictionary.

Thus, as a first stage the document (or part of the document) isinspected to make note of the tag types that appear in the document.During the document encoding process, XML tags are replaced with tokens.Tokens are a short pattern that represents the tag. For instance, thetag type Invoice can be represented as the much shorter tag A. The tokenB could represent the tag Buyer. Seller could be token C, Number couldbe D, and so on. The short representation facilitates the compressiondiscussed above.

Before assigning a new token to a tag type, reference is made to a tokendictionary. This token dictionary works for illustrative purposes like atypical English dictionary in that it stores words and their meanings.By this preferred embodiment the token dictionary stores tags and theirtokens. Some words in the token dictionary, just like English words, mayhave multiple meanings. This overloading of entries in the tokendictionary serves an important purpose, especially in relationship toXML attributes.

Attributes are part of tags, but not part of a tag's label and not aproper child. Like a child, however, attributes are subordinated totheir parent tag. However, this fact alone does not demand specialtreatment when indexing. When considering Indexing (as will be discussedin more detail below) problems may arise when attributes have the samename as tags. For instance, this is an XML tag where the tag type (name)and attribute type (name) are identical:

<name name=“partOfAttribute”>partOfTag</name>

To avoid confusion when searching an XML document, the token dictionary,by this embodiment, would contain two entries for “name,” one for whenit is used as a tag type, and one for when it is used as an attributetype. This in certain respects is similar to an English dictionary thathas multiple entries for words that can be used as different parts ofspeech.

In accordance with another preferred embodiment this idea can be furtherextended to semantic distinctions. Users could attach different meaningsto like terms in the token dictionary. Such semantic distinctions thatare introduced to the dictionary can be utilized by semantic reasoningengines (which do not form part of the invention) in order to determinethe semantic meaning of the specified terms (e.g., for determining thatthe tag Jaguar is referencing a type of car and not a type of feline).Of course, the default, automated behavior of the token dictionary onlydistinguishes between tags and attributes and does not provide thepertinent semantic analysis. However, without the token dictionary, thissort of tagging is not practical. Even with structural annotations,relational indexes such as inverted lists do not support this idea.

There are potentially numerous representations of the token dictionarythat would be created for the XML document (10) shown in FIG. 1 (and thecorresponding intermediate tree (20) shown in FIG. 2). One suchrepresentation (30) is shown in FIG. 4. This token dictionary has asingle entry for each XML tag or attribute. For example, the entry for“Invoice” in the dictionary corresponds to the token “A.” These mappingsare used to generate the sample XML tree seen in FIG. 3.

The construction of the Token dictionary (40) of FIG. 4 involves by oneembodiment the following steps: each tag or attribute is assigned with atoken from the dictionary. If a tag type does not appear in thedictionary, a new token is created. After replacing all tags andattributes with tokens from the token dictionary, the XML intermediatetree (30) looks like FIG. 3. It may seem that the tree in FIG. 3 is notthe same as the tree FIG. 2. The difference comes when the attributesare turned into token/label pairs.

In the tree (30) of FIG. 3, tokens have replaced the tag and attributetypes. Once the tokens have replaced the tag and attribute types, thenew document is almost ready to be indexed. The only remaining caveat isthe notion of order among document siblings.

In accordance with one embodiment, the entire process that transformsthe XML tree representation (20) in FIG. 2 into the XML treerepresentation (30) in FIG. 3 can be summarized as follows:

-   -   1. All attributes (e.g. Count, Discount 24 and 25, respectively)        are changed from octagons to solid boxes that contain the        attribute name with a subordinate dashed child box that contains        the attribute value.    -   2. All values in solid boxes (e.g. Buyer, Seller and Number 21        to 23, respectively) are replaced with the appropriate tokens        from the token dictionary.

Note that this entire encoding process (i.e. from the XML of FIG. 1 tothe tree representations of FIGS. 2 and 3) is automated and notnecessarily visible to human operators. It should be further noted thatthe process does not have to be completed to this level of detail, e.g.with varying boxes and line styles to represent the different parts ofan XML document. This level of detail is shown for clarity ofexplanation. In general, the input XML document is represented as treestructure with tags and attributes replaced by tokens. The resultingdata structure can be stored and indexed, as will be explained ingreater detail below.

Before proceeding further to describe the remaining step of creating theencoded strings of arbitrary length, there follows a short discussionabout the notion of sibling order. The idea of “order” (ordinalinformation) is very important for some documents, and not at all forothers. For example, in research papers, the “first author” is generallycredited with the lion's share of the project effort. On the other hand,given a grocery receipt on which “carrots” appear before “corn,” ordercarries little significance.

Thus, in accordance with a preferred embodiment of the invention,sibling order is represented through a special application of tokens.Other approaches annotate objects (data items) with their “ordinalnumber” or use explicit pointers of some sort for object chaining. Thisheavy handed approach requires that the index structure is aware oforder, and deals with order in a different manner from other properties.This increases the complexity of the storage mechanism, but does notlend any unique advantage. The main problem with these other approachesis that they impose restrictions on the indexing and storage mechanisms.A generalized representation should not be restricted to specificimplementations. As will be explained below, a better approach is to usethe explicit sibling order in the document as an implicit tag.

In accordance with this specific embodiment, there is a special token(say, “O” (51) in FIG. 5 below) in the dictionary that is never used torepresent an explicit tag type or an attribute type. This token is onlyused to represent sibling order. In FIG. 1 there are three Items:widget, thingy, and jobber (in that order). In a general data structure,such as a trie or the Layered Index, objects are orderedlexicographically. In this case, the trie or the Layered Index wouldstore the objects in the following order: jobber, thingy, widget. Thisis the precise opposite of the order these objects appeared in theoriginal document: widget, thingy, jobber. To solve this problem,without imposing a restriction on the search and storage mechanism, thesibling order is represented as its own token (O).

FIG. 5 shows where a special token would be leveraged to preserve order.The O tag (51) represents a token that did not explicitly exist in theoriginal document, even though the order was explicitly present (inother words, the order of widget, thingy, and jobber is evident from theoriginal document). The edges (52, 53 and 54) of the O tag are labeled(say, with ordinal number in ascending order that corresponds to theordered items widget, thingy, and jobber, respectively) and thereafterindexed. Whereas with the “O” token explicit sibling order isrepresented, the invention is not bound by this specific form of order.Accordingly, if desired a different token (not shown) can representnon-explicit sibling order, say the reverse order (e.g. jobber, thingy,widget).

The method described above is quite effective at supporting arbitraryqueries, where users do not even need to know the data types present inthe database before starting a search. In cases where there isforeknowledge about the queries that will be run over the database, evenbetter performance can be achieved.

Thus, in accordance with a modified embodiment an encoding scheme(referred to as the “smart path”) is implemented. By this approach, whenthere are identifiable queries that appear more frequently than others,or some set of queries that represent all possible queries for a givendata set, there is no need to store the full set of details and inparticular the full path that corresponds to the specified query. Hence,instead of indexing the full (raw) paths, the corresponding (short)smart paths are indexed. The short path (rather than the explicitoriginal path) is, thus, non-explicit. If addition, or alternatively,smart paths may include paths that are completely non-existent in theoriginal data.

For example, consider the invoice document shown in FIG. 1. If userswill never look for the “Invoice→Seller” path, there is no reason toencode and index that path. This might be the case when the onlyinvoices appearing in a department's database have that department asthe “Seller.” Regardless of the reason, there are times when only partsof the data set are interesting to potential users.

Assume that one important query type simply looks for items sold,without regard to buyer, seller, invoice number, etc. This type of querymight be important to a group performing an inventory analysis. Based onthe paths in FIG. 2, the interesting path is “Invoice→ItemList→Item.” Inmost known indexing schemes this path represents three steps in theindex.

In accordance with the present modified embodiment, instead of indexingthe path “Invoice→ItemList→Item” (explicit in the document) to identifyan “Item” in the database, a “smart” path (non-explicit) called“SmartItem” (or any name) is indexed. At the end of the “SmartItem”paths would be the same data that was at the end of the original“Invoice→ItemList→Item paths.” Of course, the descriptive name“SmartItem” would be replaced by an entry from the designatordictionary, say “X.” When performing the lookup for “Invoice” in thetoken dictionary, all smart paths that begin with “Invoice” are found.

Using smart path indexing can save considerable space in the index (ifit replaces the original raw index). It is important to note that smartpath indexes do not influence the storage of the original data.Techniques that do not alter the original data are certainly preferredto those that affect the data. By leaving the original data pristine,multiple indexes can be built (including, if desired, multiple pathsthat lead to the same data item), or data can be used for other tasks,all without translation back into the original format. Additionally, itrequires less effort if an index can be built without costly datatransformations.

Smart paths are but one additional way to leverage the proposedtechniques to provide enhanced performance under specific conditions. Bycoupling the token dictionary with techniques designed to capture therelationships inherent in semi-structured data, many indexingpossibilities arise. When using one of these alternate encoding methods,like smart paths, the index always achieves better performance than afull index (as discussed in detail above), but can only support aportion of the space of possible queries. This tradeoff can be used toachieve an optimal balance somewhere in between the basic implementation(useful to ad hoc and less frequent queries) and smart paths (useful topre-defined and frequently asked queries), or can even be used to coupledifferent approaches in tandem. There is no limit to the encodingtechnique, only certain practical limits imposed by the availablehardware of the day.

The various preferred embodiments described above are only instances ofthe more general concept of representing semi-structured data as datastrings of arbitrary length. In accordance with the proposed approach,the encoding technique can represent semi-structured data as stringinformation, where some of the information comes directly from theoriginal data and some of the information comes from the tokendictionary. As will be shown in greater detail below, indexes can bebuilt using those strings, and those indexes can achieve much betterperformance than traditional indexes. The encoding maintains thestructural (specific examples are the path information and sibling orderinformation) and non-structural information.

In this context, the term “structural,” as used in the phrase“structural information,” refers to how objects or data items arerelated to one another. There are many properties and relationships thatfall into the category of “structural.” Relationships between objects,such as parent-child relationships, are structural information. Elementordering among sibling objects is also structural. Paths formed byrelationships between multiple objects are also structural. Theseexamples give an indication of what composes structural information. Interms of XML data specifically, structural components include markup(“tags”), properties (“attributes”), and relationships such as elementnesting and sibling ordering, as well as paths formed by suchrelationships.

Non-structural: “Non-structural” is easily defined in terms of itscounterpart, “structural.” “Objects” or “data” generally representnon-structural information. Objects are related in certain ways, andtheir relationships combine with the objects themselves to form completedocuments. In terms of XML data specifically, non-structural componentsinclude the content that appears between the markup tags.

In a string encoding of XML, concatenating strings captures i.a.parent-child relationships. Using the data in the Token dictionary ofFIG. 4, one possible conversion of the XML into strings of arbitrarylength is shown in FIG. 6.

To generate the contents (60) of FIG. 6, all the paths from the root ofthe XML tree (shown in FIG. 3) are written in the “XML path” column.Then, the arrows from parents to children are erased, and the resultingstrings are written at the corresponding locations in the “XML pathstring” column.

This is but one possible representation of the XML as strings. There aremany different possibilities. For instance, in accordance with onepreferred embodiment when the XML has labels at many levels in the tree,not just at the leaves, the tokens (as in FIG. 6) may be prefixed. Inaccordance with another preferred embodiment an infix notation is used,distributing the tokens among the labels in the strings. By anotherpreferred embodiment that handles arbitrary collections of stringsefficiently, both approaches (infix and prefix string encoding) havedistinct advantages.

In those embodiments in which element ordering is significant, thesolution that provides storage of ordinal information (discussed above,e.g. using the O token) can be used. If desired, the use of the ordersensitive solution (e.g. with the O designator) to represent order canbe the default behavior of the index, It should be noted, however, thatthere are data sets for which it provides no benefit. It appears, thus,that the database administrator is the best arbiter for the decision tostore ordinal information in the index.

The string of arbitrary length maintains the structural informationincluding the path (explicit and non-explicit, say, in the case of smartpaths).

Whereas the string of arbitrary length (see, e.g. the strings entries 62and 63, being of different length) are in compressed form (since theoriginal longer tags and tokens were encoded by shorter tokens), this isnot necessarily always the case and thus other encodings that do notnecessarily achieve compression may be used, depending upon theparticular application.

It should, likewise, be noted that whereas the description aboveillustrated the encoding through the use of intermediate trees (FIGS. 2and 3), the invention is by no means bound by this specific route, andother implementations that receive as an input an XML data orrepresentation thereof and encode it (or part thereof) into strings ofarbitrary length are applicable.

Having encoded the data it can now be indexed to facilitate efficientaccess. The access will enable i.a. content based access andstructure-based access to thereby afford searching browsing and otheroperations.

There follows now a description for a specific embodiment of indexingutilizing a designated index, preferably a layered index. Layered indexand designated index are discussed in detail in U.S. Pat. No. 6,175,835.

The Layered Index structure is particularly well suited to indexing andsearching XML. Coupling our techniques for tokenizing XML with theLayered Index structure yields performance results and system propertiesnot attainable in other implementations.

Since the Layered Index is an index, and not a complete DBMSimplementation, it can exist above standard implementations and provideenhanced query performance. At the same time, the Layered Index canleverage the facilities provided by the database below it. For example,there is a system called STORED (Semi-structured TO Relational Data)that discovers ways to bulk load semi-structured data into a relationaldatabase in an efficient manner (see: “Storing Semi-structured Data withSTORED,” by Deutsch, et al.). The STORED system is very good for an apriori load analysis, and generates relations that are designed for goodperformance under various conditions (such as a given query mix or anallowable amount of wasted space). The Layered Index can sit atop arelational system like STORED, leverage its myriad strengths, andsimultaneously overcome many of its shortcomings because of itsrelational nature.

The Layered Index can be browsed, searched by structure, and has otheradvantages that a relational system like STORED does not supply.Additionally, the Layered Index fits in main memory for millions ofobjects, and usually requires only one I/O to search and update withinbillions of objects. This is a clear performance gain that is notapproached by relational systems. By coupling the two, the Layered Indexgains from the database beneath it, while the database gains from theLayered Index. For XML, the performance gains from the Layered Index aresubstantial.

This decoupling of the index from the primary storage system means thatdeficiencies in the storage system can also be overcome at the indexlayer, before penalties are paid at the data storage layer. For example,STORED remains efficient at some points by storing nonconforming dataitems in “overflow buckets.” These buckets are expensive to search inthe storage layer, but are used because they can save significant space,or reduce the number of required tables. By tokenizing the XML andindexing it with the Layered Index, the complete structure of the XMLforced into overflow buckets by STORED still appears in the index andthus, can be searched efficiently. No information is lost because of thestorage mechanism.

Another advantage of this decoupling is that the Layered Index can growarbitrarily without suffering performance penalties present in thestorage system below it. STORED is an effective mechanism for pushingsemi-structured data into a relational database because it can see allthe XML data at load time. What happens when new data is added to aSTORED database that does not conform to the data initial used toconstruct the database? The advantages of using STORED are incrementallydiminished with each new non-conforming XML document, The Layered Indexsuffers no such penalty. In fact, as the population of XML documentsincreases, the PATRICIA structure at the foundation of the Layered Indexbecomes more accurate.

In relational systems, there is a trade-off between effective indexingand efficient storage size, which is a tradeoff the Layered Index doesnot have to make. Since the Layered Index stores (by one embodiment)PATRICIAs that are a structure fundamentally related to an XML tree, theprecise amount of information needed for complete indexing is stored.With a relational table, sparse data is fundamentally wasteful to store(because of null values); this is not the case in the Layered Index.With a relational table, dense data is fundamentally wasteful to index(because complete keys are indexed); this is not the case in the LayeredIndex.

Finally, there are advantages to indexing XML with the Layered Indexthat cannot be realized in any complete-key indexing scheme or in arelational database that explicitly stores complete documents. Theunderlying PATRICIA compresses the keys in the Layered Index, such thatvery little space is required to index a document. The Layered Index canindex an arbitrary length key in a new XML document with only a singlesymbol from that key. This means the Layered Index can be maintained inmain memory for millions of objects when those objects are XML. Completekey indexes, such as B-trees, grow not only with the number of objectsindexed, but with the size of the index keys as well. With arbitrary XMLdocuments, B-tree performance cannot be bound (or even estimated) in anyreasonable way.

Turning now to a specific example of indexing using a layered index,U.S. Pat. No. 6,175,835, highlighted the usage of designators (page 25of the patent) and subordination of data records to describe the dataelements and their relationships.

By one embodiment of that patent exemplified in FIG. 13E two datarecords designated B (812 and 820 in the drawing) and one recorddesignated D (824) are subordinated to data record designated A (806). Adesignated index allowed search over designated data records. Anotherembodiment deals with the creation of a layered index to allow efficientsearch. An example of such is shown in FIG. 7H of that patent.

The usage of designated data and subordination relationships forsemi-structured data can be exemplified by a) using a set of rules andor knowledge and or formula to map the semi-structured data todesignated data records where each such designated record can be asubordinated record; b) combining the designated records into stringsthat can represent structural and non-structural information that iseither explicit or not explicit in the original data item; and c)creating a designated index in which part or all of each string istreated as a key, thereby enabling search over this set of designatedrecords. In a preferred embodiment such index would be a layered index.The designated records being an example of data items.

To exemplify step a) of the above, FIG. 7 shows the mapping of the XMLdocument of FIG. 1 to designated data records (70). These records mustbe long enough to contain the designator and the associated informationand may further be padded with extra space. To create the designatedrecords, each tag and attribute that appears in the original document isreplaced by a designator obtained from the token dictionary of FIG. 4.For tags, the created record contains the concatenation of thedesignator with the data that is associated with the tag. In the exampleof FIG. 7, the seller's <Address> was mapped to a record designated Gappended with the data “17 Business Circle” (74). If the tag has noassociated data, then a unique identifier is created and appended to thedesignator. For example, in FIG. 7, the tag Invoice was mapped todesignator A (71) and appended with the identifier 001 (72) since thetag <invoice> in the XML document had no associated data. Forattributes, the designated record is constructed by concatenating thedesignator and the attribute value (with additional optional padding).In FIG. 7, the attribute—discount—was mapped to a record designated J(75) with a key that includes the discount value (0.10) (76).

The parent-child relationships among tags and between attributes and thetags that contain them are represented by the subordination of thecorresponding designated records. The subordination is derived from thehierarchical nature of the XML—in FIG. 7 for example, since <buyer> is achild of <invoice> the record designated B (77) is subordinated to therecord designated A (71).

In step b), the designated records are encoded into strings of arbitrarylength based on the subordination relationships or other relationships.For example, some strings that would be created from the records in FIG.7 include, the string “A001+”, “A001+B002+”, and “A001+B002+FABCCorp.+”, where the “+” signs represent spaces to pad each component (toa length of 100 characters). It is important to note that the padding to100 characters is just one example, as the strings created by themapping can be of arbitrary (possibly different) lengths.

The next step of the encoding concerns the insertion of the strings intoan index. FIG. 8 shows a specific case of Patricia structure (80) overthe strings obtained from the designated records of FIG. 7 in anembodiment similar to the embodiment of FIG. 13E of the above U.S. Pat.No. 6,175,835.

A Patricia structure is an index structure derived from a trie such thatonly nodes that have at least two children are maintained. Since thenodes with one child are compressed the nodes in a Patricia includes thedifferentiate key position. Because of that compression, the size of thePatricia structure might be less than the aggregate size of the keysaddressed by the Patricia. For a more detailed discussion on Patriciastructure see Donald E. Knuth, The Art of Computer Programming, Volume3/Sorting and Searching, page 490-499. In FIG. 8, the dark circles anddark lines represent the Patricia nodes and links.

In the example of FIG. 8, nodes address byte offsets (shown as a numberwithin each circle), the size of the designator is assumed to be 1 byte,and the rest of the record's key fields are padded to 100 bytes asdescribed above.

For example, the root node (81) maintains the value 100 that relates tothe designator position of records B, C, D and E (82 to 85,respectively) all of them subordinated to the same A record 86. Theleftmost node with the value 200 (87) relates to the designator positionof records F and G ((88) and (89) respectively) that are subordinated torecord designated B (82) with the key value of B002.

The arrows such as from record B002 to A001 maintain the hierarchicalrelationship between the records with the strings generated in step b.These links can exist in one embodiment as physical link from a childrecord to its parent record.

A similar example is shown as links 826, 828 and 830 in FIG. 13E of theabove U.S. Pat. No. 6,175,835. FIG. 13D of the above patent exemplifiesanother embodiment in which each designated record (such as records 812,820 and 824) physically includes (at least) the hierarchical key.

FIG. 9 presents the result of implicitly maintaining the designators inthe index structure of FIG. 8. The resulting structure deviates from aPatricia structure in that the structure of FIG. 9 (90) includes nodeswith only one child. The (non-straight) arrowed links from a childrecord to its parent (such as in FIG. 8) are not shown for convenience.An alternative link from a node with a value that relates to adesignator position in the key to the parent record was added as astraight arrow.

It can be easily seen that the size representing a key in this Patriciastructure is smaller than the original key size. The key for the buyername once mapped to the designated record F is a concatenated key thatincludes the invoice and the buyer thus being A001+B002+FABC Corp. Whilethis key is 300 bytes long, the space needed to represent this key andits hierarchy in the Patricia structure of FIG. 9 will typically be muchless. This space includes at most, the root node (91) with the value 0,the link labeled A (92) from that root to the child node having thevalue 100 (93), the link with the value B (94) from that node and itschild node with the value 200 (95) and the link labeled F (96) from thatleaf node to the data record FABC Corp (97). In a specific embodiment, anode and the links between nodes can be represented by 2 bytes each anda link to data record by 4 bytes, the 3 nodes and 3 links with extraoverhead would take only 20 bytes which are less than 10% of the size ofthe keys making up the path.

The structure of FIG. 8 and the structure of FIG. 9 could both be madeinto a basic partitioned index, Since the unbalanced nature of the triea layered index can be formed in a way described in U.S. Pat. No.6,175,835.

FIG. 10 shows the structure of FIG. 9 as a basic partitioned index((101) in layer I₀, and an additional index layer (102 layer I₁) overthe representative keys of the blocks of the layer I₀ constituting arepresentative index (the data records and the links to the data recordsare omitted for convenience).

Once a representative index is formed the search to the designated datarecords would start at layer I₁ (102) (and in the general case at layerI_(k) where I_(k) is the root index) to reach the block at I₀ (101) thatis associated with the record whose key is searched. This would be donein a balanced manner (the additional I₁ to I_(k) layers constitute abalanced structure of blocks) all as explained in the above patent.

In order to calculate how much memory is needed to maintain the non-leafblocks of the layered index (the representative index) we will assumethat every new key that is added to a Patricia structure (in I₀ (101))adds about 10 bytes to the size of the Patricia (4 bytes to maintain thephysical address, 1 byte for the label and some overhead).

Assuming that every block is 8K bytes in size and on the average about70% full, about 560 elements can be represented by a single block(8000×0.7/10). One million elements would be represented by about 1786blocks. The representative index would index the representative keys ofthe 1786 blocks with again about 560 elements per block thus with about3 blocks of 8K bytes each (about 24K bytes of memory). Thusapproximating—for representing additional about 1 million elements inthe index, about 25K bytes of internal memory are needed in order tomaintain the additional non-leaf blocks in the internal memory. This, ofcourse, is only an example and the invention is by no means bound bythis example.

FIG. 11 exemplifies an alternative path (Smart Path) to data recordsrepresenting names in the original XML document of FIG. 1 (i.e. [F ABCCorp.] and [F Goods Inc.]) Rather than following the document structure(for example: by the key “A001+B002+FABC Corp.+”) it is possible tosearch by the key “FABC Corp.+” since the key represented by the SmartPath is of the designator F followed by name (the path of the nodes andlinks—110, 117, 118, 119 to data record 116 rather than 110, 111, 112,113, 114 and 115 to data record 116). Obviously if the informationavailable for the search is only of the company name, this search wouldbe more efficient than the search that follows the document structure.

Obviously other alternative path and Smart Paths are possible.Alternative paths can lead also to permutation records such as forexample the one shown in FIG. 14 of U.S. Pat. No. 6,175,835.

With a layered index, the search through the unbalanced structure of thebasic partitioned index structure is replaced by an essentially balancedsearch. This is the result of adding the additional representative indexto faun a balanced structure of blocks (the layered index). Since anindex with three layers can address billions of data items (regardlessof the size of the key) and the footprint of the first two layers isvery small and could be maintained in the internal memory. This index isconsidered to be more efficient than alternatives that do not have bothof the properties: (a) are balanced or (b) the growth of the index doesnot depend on the size of the key.

An additional (c) property that further improves the efficiency is thelinkage between subordinate items. In FIG. 8, if a search leads to thedesignated record “FABCCorp” (by the original structure or by asmart-path), its parents (the relevant B and A records) can be reacheddirectly (by the arrowed link). In alternative approaches to (c), asearch in a separate index might be needed.

An index such as in FIG. 8 supports browsing—for example, from the rootnode, a user would see the optional alternative links to the Buyer,Seller, Number, and ItemList (by looking at the token dictionary for themeaning of B, C, D & E respectively), and can then decide on the path tofollow.

Enabling the advantages of a smaller size, potentially short searchpaths, and balance makes the layered index considered (among othersindexes) to be more efficient than schemes that address only some of theadvantages. The proposed encoding and indexing (in particular for thelayered index embodiment) has many advantages. It is a “universalindex,” in that it can be used for any XML data. It is a “flexibleindex,” in that it can be simultaneously tuned for multiple accesspaths. It is a “small index,” in that it is generally orders ofmagnitude smaller than data over which the index is built. It is a “fastindex,” in that most or all of it can reside in main memory, and mayrequire a single I/O to address billions of data objects. In addition tothese performance metrics for semi-structured sources, it stillmaintains excellent performance over simpler “relational” data sets. Itshould be noted that an index is a useful structure because iteventually points to some information beyond itself. Frequently, indextypes are determined by the actual data that the index eventually pointsto. Traditionally, relational data is indexed by structures such asBtrees, hash tables, and inverted lists because these indexes work wellwith relational data. Object oriented databases tend to use some ofthese structures, but also lean heavily on very object oriented indexes,such as DataGuides and path dictionaries. The Layered Index approach isnot restricted by the underlying data, or how that data is managed. Theindex we construct can easily lead users to fully structured datasources, like relational databases, or to semi-structured data sources,like object-oriented databases. This index is not constrained by thedata below, and thus provides a uniform mechanism to access multipledata types simultaneously,

There follows now a short discussion in connection with improvement.Thus, after converting tags and attributes into their tokenrepresentations, several opportunities for improvement are presentedthat are not readily realizable in the native representation. First, theindex can store new compressed non-explicit paths that are not presentin the original document. The token encoding and use of the tokendictionary means that we can leverage this ability for path compressionwithout restricting the implementation. In FIG. 3, there are paths likeA→C→F (which is the path Invoice→Seller→Name seen in FIG. 2). If A→C→Fis a commonly searched path, the database administrator can make thedecision to create a new token, say “M,” that has the same meaning asA→C→F (whilst optionally retaining also the original path information).This effectively creates a shortcut so that fewer paths have to besearched (only the M branch, not the entire A→C→F path). There is anadditional savings that presents itself when similar documents areindexed, or when there are siblings that do not share the same tag. InFIG. 3 there is one A→C→F path, but there is also an A→C→G path. Withthe M token representing A→C→F paths, a partially correct path likeA→C→G never has to be checked. This is a two-fold savings from this pathcompression using the token dictionary.

There are other opportunities provided by token reordering. Oneadvantage to using tokens is that they can be reordered to providemultiple paths through an index structure, without losing anyinformation, and without complete path duplication. For instance,returning to FIG. 3, there is an A→C→F path that leads to a companyname. This can be reordered and stored as F→C→A, but still point to thedata item “Goods Inc.”, to thereby accomplish more than one path thatlead to the same data item. This type of reordering is possible withinan index built on tokens, but not readily realizable in a relationalsystem. Reordering paths in a relational system (and maintaining goodsearch performance) requires duplication of tables or using materializedviews. Either potential relational solution is very costly in terms ofspace.

Beyond simple path reordering, paths may also be “shortcut.” Instead ofusing an M to represent A—C—F users may be interested in all F tokens(Buyer and Seller Names in FIG. 1). Since the XML is stored as a tree,searches begin at the root of the tree and proceed downward. Whenlooking for just F tokens, the entire document tree must be searched tofind the F tokens. An obvious solution is to use an external index, likean inverted list, to store all F tokens and do lookups from there. Whileobvious, the inverted list requires space beyond the main index, it addsthe complexity of maintaining two types of indexes, and adds the cost ofmaintaining strict integrity constraints between the inverted list andthe main index during inserts, deletes, and updates.

A more direct and consistent approach would be to add paths from theroot with the F token that pointed directly to the F objects. An exampleof this type of shortcut is shown in FIG. 12. With this approach, alloriginal paths are preserved, but quick access to particular objects isalso allowed (as well as in FIG. 11).

Having referred to issues of optimization, there follows a discussion,which exemplifies querying over semi-structured (XML) data that isindexed by a layered index, in accordance with a preferred embodiment ofthe invention. The invention is by no means bound by this particularquerying and indexing example.

Generally speaking, queries over relational data sources returnrelational data. It is a simple task to query a relational source usinga modern query language, such as SQL, because the schema is fixed. Afixed schema means that users know what the returned data will look likeat the time they pose the query. It also means that the queries aresimple to formulate.

Queries over semi-structured data sources are a bit more difficult tohandle. Users may not always know at query time what the results shouldlook like. Semi-structured queries should return whatever available datamatches the query. In the case of XML data, this means returning an XMLfragment that corresponds to a subtree that has certain propertiesspecified by the query. For example, reverting to FIG. 1, one may askfor “Invoice→Buyer,” where “Invoice→Buyer→Name=‘ABC Corp.’.” This isequivalent to asking “give me the address information from an invoicewhere the buyer is ABC Corp.”

The portion of the query “Invoice→Buyer→Name=‘ABC Corp,’” corresponds tofinding XML of the form <Invoice><Buyer><Name>ABC Corp.</Name> . . . andreturning the entire subtree rooted at <Buyer>. The “projection” stepconsists of simply finding and returning the appropriate <Buyer>subtree, though more expressive languages may allow for transforming the<Buyer> subtree into a new tree.

By examining current academic and industrial papers on semi-structuredquery languages, (such as Lorel, XPath and Quilt see

-   -   S. Abiteboul, D. Quass, J. McHugh, J. Widom, and J. Wiener. “The        Lorel Query Language for Semistructured Data.” International        Journal on Digital Libraries, 1(1):68-88, April 1997.    -   XML Path Language (XPath), Version 1.0,W3C Recommendation 16,        November 1999, Editors: James Clark, Steve DeRose.        http://www.w3.org/TR/1999/REC-xpath-19991116.html    -   D Chamberlin, J Robie, and D Florescu. “Quilt: An XML Query        Language for Heterogeneous Data Sources,” International Workshop        on the Web and Databases (WebDB'2000), Dallas, Texas, May 2000.)        one finds the following primary query predicates for        semi-structured data:

1. Structural existence: find XML fragments that have a particularbranching structure, e.g. <A><B></B><C></C></A>, where <A> may not bethe root.

-   -   Rooted structural existence (special case): find XML documents        with a certain structure, starting at the root.

2. Simple path expressions: find XML of the form A→.B→C=“XYZ” (where <A>may not be the root)

-   -   Rooted simple path expressions (special case): find XML of the        form root→A→B→C=“XYZ”

3. General path expressions: like simple path expressions, except thatwildcards may be used:

-   -   A→(S1|S2)→B: a path looks like either A→S1→B or A→S2→B    -   A→(S)?→B: A path may or may not have S, e.g. either A→S→B or A→B        matches    -   A→(S)+→B: A path with one or more S components, e.g. A→S→B,        A→S→S→B, A→S→S→S→B, . . .    -   A→(S)* →B: A path with zero or more S components    -   %: A wildcard for characters in a component label. e.g. A→S%→B        looks for labels starting with S, A→%S%→B looks for labels        containing S, etc.    -   A→(%)*→B: Find an A, followed by any number of labels with any        name, followed by a B

4. Path expressions with text intermixed: A particular child is followedonly if that child encompasses certain text, e.g. A→B only if A's textis “foo.”

5. AND: Find a subtree with two properties, e.g. Find A→B such thatA→B→C=“foo” AND A→B→D=“bar”

6. OR: Find a subtree with either of two properties, e.g. Find A→B suchthat A→B→C=“foo” OR A→B→C=“bar”

7. Order: Find a subtree where the nth child is X, the mth child is Y,etc. English examples of queries involving order are of the form: “findDBLP records where the first author is ‘Brian Cooper’” or “find invoiceswhere the first item is ‘hammers’ and the second item is ‘nails’.”

In a database management system, the “query processor” component answersqueries using a tree of query operators. Each query operator performs asimple task. Complex queries are formed by combining multiple operators.In the case of Layered Index, the following operators are useful:

-   -   Key lookup: Look for a complete key in the index and return the        associated pointer (or set of pointers) to data. For example, if        the key is “ABC foo,” then look for that key by traversing the        Layered Index to the leaf, and retrieve the pointers from the        leaf.    -   Prefix key lookup: Look up the prefix of a key in the index, and        return all of the children of that prefix in the index. For        example, the prefix may be “AB,” and looking up this prefix will        allow us to find “ABCfoo,” “ABDbar,” “ABbaz” and so on. Prefix        search means finding a node in the vertical portion of the        Layered Index, and then traversing the entire subtrie rooted at        this node to find all of the leaves and pointers. The horizontal        index is followed according to the prefix until getting to a        leaf block of the index, and in the leaf block the node that        represents the prefix is found. Then, the vertical index is        followed wholly within the leaf layer to find all of the        children.    -   Pointer set intersection: Perform an intersection over a set of        pointers.    -   Pointer set union: Perform a union over a set of pointers.

Turning now to smart paths (constituting non-explicit structuralinformation that is associated with the data as they may not appear inthe original XML data), it may be recalled that smart paths correspondto particular queries. These queries may be parameterized, e.g. “Selectinvoices where the buyer is X and the seller is Y.” Such queries implythe existence of a particular structure coupled with certain data valuesat the leaves of that structure. The structure may be very general, forexample corresponding to a general path expression.

Answering a query for which there are smart paths is straightforward. Ofcourse, a query must supported by an existing smart path to use thisapproach. A query parser could determine if a posed query overlaps anavailable smart path, even if they have slightly different forms.Imagine a smart path that represents “<Invoice><Buyer/><Seller/> . . . ”with a designator “Z” in the Layered Index. For the query “Find invoiceswhere the buyer is IBM and the seller is RightOrder,” the queryprocessor extracts “IBM” and “RightOrder” and forms them into a key like“ZIBMRightOrder.” After that, the query processor uses the key lookupoperator to find the documents that match this query. This entails asingle index lookup since the query processor needs to search for onlyone key.

In some cases, smart paths can support queries that do not exactly matchthe intended query. For example, a template for finding invoices with aparticular buyer and seller can also support the query “Find invoiceswhere the buyer is X.” This is because the query can be answered bylooking for keys prefixed with “Zbuyer.” Again, one can use the prefixkey lookup operator to find the answer to the query. On the other hand,it is difficult to use the same smart path for the query “find invoiceswhere the seller is Y,” since that requires looking for keys of the form“Z*seller,” where the * is any string. Thus, to answer the query usingthis smart path, it is required to “skip over” the middle component ofthe key, which is potentially very hard to do. However, smart paths werenot intended to support arbitrary queries, just those that the databaseadministrator optimizes for before query time.

Turning now to the original paths (constituting explicit structuralinformation that is associated with the data as they appear in theoriginal XML data), they are present in the original semi-structureddata, reflect the complete structure of the data, and thus support morequeries. However, because the paths are structured like the data, andnot like the queries, these paths may be more difficult to search thansmart paths. (Since smart paths never require more than one lookup for aquery, it is actually impossible to be more efficient than smart paths,but some queries will be “as good.”)

In the discussion below there are shown some ways of handling thesemi-structured queries (listed above) using the original pathinformation. There may be more efficient techniques that require furtherexploration, but here are some techniques to use the index to supportparticular query types. The invention is of course not bound by thespecific examples discussed below.

Rooted Structural Existence:

To find documents containing a particular structure starting at theroot, the query structure is encoded in the same way that the originalpaths are. For example, a query of the form “Find documents with<A><B><C>” becomes a query for “ABC” (if A, B, and C are the tokens for<A>, <B> and <C>). This query likely corresponds to a prefix of a set ofkeys inserted into the index. For example, if documents are structured<A><B><C>data</C></B></A>, there will be keys of the form “ABCdata.”.The prefix key lookup operator is used, searching for “ABC,” to find theanswer to the query.

Rooted Simple Path Expressions:

These queries look for a constant at the leaf of a path, and correspondto a complete root-to-leaf traversal of the Layered Index. Consequently,a search key can be formed in the same way that the original paths areformed, and use the key lookup operator. For example, if the query is“find documents with <A><B><C>data</C></B></A>,” a complete key“ABCdata” is formed and thereafter a single lookup in the Layered Indexfor that key is performed.

Path Expressions with Text Intermixed:

Consider the following semi-structured data fragment:<A>alpha<B>beta</B></A>. The text elements “alpha” and “beta” areleaves, and this fragment can be encoded as two keys: “Aalpha” and“ABbeta.” Previous work takes this approach to data encoding multiplepaths, and it can be supported in the Layered Index. (e.g. Lore, Xpath,specified above).

If users want to search for “<A>alpha<B>beta,” there are threeoperations:

-   -   1. Search with the key lookup operator for “Aalpha”    -   2. Search with the key lookup operator for “ABbeta”    -   3. Use the pointer set intersection operator over the results of        1 and 2 to yield candidate results

General Path Expressions:

These queries can be divided into two classes: queries that can beexpanded into a finite set of simple path expressions, and those thatexpand to an infinite set of simple path expressions. For example,A→(S1|S2)→B expands to two queries, A→S1→B and A→S2→B. In contrast,A→(S)*→B expands to an infinite set (e.g. A→B, A→S→B, A→S→S→B, etc.), asdoes A→(S)+→B.

If the query expands to a finite set of queries, the query processor canrun each query individually using separate key lookup operators. Thisrequires multiple traversals of the Layered Index, but each simpletraversal is efficient, so the query is answered relatively efficiently.For example:

-   -   Query: A→(S1|S2)→B    -   Search: A→S1→B and A→S2→B    -   Query: A→(S)%→B    -   Search: A→B and A→S→B    -   Query: A→S%→B    -   Search: look in the token dictionary for all tags that start        with S. Then search for A→S1→B, A→S2→B, A→S3→.B . . . where S1,        S2, S3, etc. are the tags that start with S    -   Query: A→(S)?→(T)?→B    -   Search: A→B, A→S→B, A→T→B, and A→S→T→B

It is possible that the finite set of queries is actually quite large.For example, the query A→B%→C%→D%→E%→F could be expanded to many queriesif there are many tags that start with B, C, D and E. In this case,there are other approaches to naively running all of the queries; thesetechniques are well known per se and therefore will not discussedherein.

If the query expands to a finite set, then it is harder to answerefficiently. This happens when the query includes * or +. In this case,the query processor can follow every path that looks like it might matchthe query. For example, A→(%)*→C means “find every C that has anancestor tagged A.” To answer this query, the processor starts by usingthe prefix key lookup operator to search for the A prefix, and thenfollows every child of the A prefix node to see if there is a C tagsomewhere below. Alternatively, the general prefix key lookup operatorcould return all children of the A prefix, and then the filter out thechildren that did not have a C tag subordinated.

Nonetheless, this approach is still potentially expensive. Maintainingan external DataGuide and/or structural statistics could be useful forallowing the query processor to prune much of the search space. Forexample, the query processor may look in a DataGuide to find that A→B→Cand A→D→C exists, but that no other paths could match the queryA→(%)*→C. Thus, the query can be answered by using just two key lookupoperators to search the Layered Index, one for A→B→C and one for A→D→C.

AND:

The AND of two search predicates can be answered by running bothpredicates and taking the intersection of the results using the pointerset intersection operator. For example, the AND of two simple pathexpressions can be answered by creating two key lookup operators andstacking a pointer set intersection operator on top.

OR:

OR can be answered like AND except that we use the pointer set unionoperator instead of the set intersection operator.

Order:

XML query languages can specify order, e.g. “find papers where the firstauthor is X.” The original paths in the semi-structured data includeorder information but require for implementation considerations the useof ‘O’ token discussed above. Since storing order requires an additionaltoken, a query that specifies order should preferably be answered in twosteps. First, the query is stripped of order information and run as iforder did not matter. Then, the result set is inspected to findcandidates that match the desired order. This last step can be achievedeither examining the data itself, or by leveraging an available “O”token.

In summary, the main query primitives in languages like Lorel, Quilt,and XPath (among others) are supported by the Layered Index through afew simple operators. The most complicated queries may require multipletraversals through the index, but this is still superior to parsing andexamining the data, and are also better than using Btree (which alwaysrequire more traversals). The projection step of a query is handledafter the correct document or fragment is found, but that is acceptable:it is not the job of the index to do projection.

The present invention can be realized in any computer system includingbut not limited to that shown in FIG. 13. As shown plurality ofcomputers (of which only three (131) and (132) and (133) are shown) areinterlinked by means of network (130). Each computer being e.g. a PC. Inaccordance with a preferred embodiment the encoding and indexing isrealized in a server node, say (131) whereas the querying is realizedfrom a plurality of user nodes, say (132) and (133). The invention is ofcourse not bound by this embodiment. By way of non-limiting anotherembodiment the coding, indexing and querying are all performed in thesame node, and in accordance with yet another non limiting preferredembodiment each of the specified tasks is performed in a distinct node.In the claims that follow, alphabetical characters and roman symbols areused for convenience only and do not necessarily impose any order on themethod steps:

It will also be understood that the system according to the inventionmay be a suitably programmed computer. Likewise, the inventioncontemplates a computer program being readable by a computer forexecuting the method of the invention. The invention furthercontemplates a machine-readable memory tangibly embodying a program ofinstructions executable by the machine for executing the method of theinvention.

The present invention has been described with a certain degree ofparticularity, but those versed in the art will readily appreciate thatvarious alterations and modifications may be carried out withoutdeparting from the scope of the following claims.

What is claimed is:
 1. A method for transforming Extensible MarkupLanguage (XML) for querying, the method comprising: a. receiving asemi-structured data input, the semi-structured data input being an XMLdata input; b. transforming said XML data input into transformedobjects, each of said transformed objects including both: non-structuraland structural information from said XML data input, said transformedobjects being keys to be indexed to allow efficient access toinformation of interest, wherein the structural information is arepresentation of structural markup and attributes of said XML datainput, and the non-structural information represents content from theXML data input.
 2. The method of claim 1 wherein said transformedobjects are the keys being indexed, constituting an index, to allowefficient access to information of interest.
 3. The method of claim 2,wherein said index represents the parent/child relationship ofcomponents from the XML data input.
 4. The method of claim 1, whereinsaid step of transforming said XML data input includes creating orupdating an index to include hierarchical information about said XMLdocument.
 5. The method of claim 1, wherein said step of transformingsaid XML data input includes creating an index that maintains an orderof components in said XML data input.
 6. A method for transformingExtensible Markup Language (XML) for querying, the system comprising: a.receiving a semi-structured data input, the semi-structured data inputbeing an XML data input; b. transforming said XML data input into keys,each of said keys including non-structural and structural informationfrom said XML document, the keys being used to facilitate access tosearched data, wherein the structural information is the markup of saidXML data input and the non-structural information is the content of saidXML data input.
 7. The method of claim 6, wherein said transformationcreates an index to allow efficient search.
 8. The method of claim 6,wherein said transformation creates an index containing parent/childrelationship for elements in the XML document.
 9. The method of claim 7,wherein said index is a designated index.
 10. The method of claim 1,wherein said index is a designated index.
 11. The method of claim 7,wherein said index is a layered index,
 12. The method of claim 1,wherein said index is a layered index.
 13. The method of claim 7,wherein said index is based on a Patricia Trie.
 14. The method of claim1, wherein said index is based on a Patricia Trie.
 15. A method formapping semi-structured data into keys, comprising: determining anelement within the semi-structured data; creating one or more keysrepresenting said element, each of the keys including both: structuraland non-structural information from the semi-structured data, whereinthe structural information is derived from structural markup andattributes of said XML data input, and the non-structural information isderived from content of said XML data input.
 16. A computer programproduct that includes a storage for storing an index over keys, and saidkeys were created according to the method in claim
 15. 17. The computerprogram product of claim 16, wherein said index is a designated index.18. The computer program product of claim 16, wherein said index is alayered index.
 19. The computer program product of claim 16, whereinsaid index is based on a Patricia Trie.
 20. The computer program productof claim 16, wherein said index is partitioned into blocks, and thestructure within the blocks of the said index is based on a PatriciaTrie.